Quicの話 ある日のミートアップ

概要

udpが通じない場合はhttp/tcpにフォールバックしてる

壮大なABテストされてるなあ。

PCの方がモバイルよりも受けてる恩恵が小さいのはなんでだろう

・まずこれらを比べることは困難

・データセンタへの接続とか、IPの変更がエフェクト出してる。改善率が低いのはそのせい？

いろいろ前提がよくわからん図

でも改善するための指標としてこういう実験が背景にあるのはすごく羨ましい。

解決すべき問題に対して理解が深められてそう

Rebuffer rateが100%になったケースが93％なるほど

クソ遅い環境(インドとか300msRTT medium)に対して、8%の改善があったみたいな話

なるほどな～遅い環境ほど改善率がある技術。底上げができる感じ。

sigcomm QUIC 2017あたりで検索するとデータが引っかかるようになりそう。

別の話

HTTP over QUIC

1本のstreamにはヘッダがカウンターしてる

- 3,2,1 ->

<- 1,2,3 -

・他のにデータが流れてる

か、

ヘッダに1本

データに1本

のペア x N になる(予定？)

フレームタイプの削除

WINDOW_UPDATE, PING, RST_STREAM, GOAWAY とかはquicが提供する。

セッティングの交換

quicがハンドルするんでいろんな設定が消えるが、

どうやってそれを周知するか(ack)

セッティングのack

SETTINGS_ACK 

これが送られてくるstreamが最後のstream(それ以下のstreamしか使われない

そのへんが使われる。

header compression

udpなんで順番は全くない。で、通し番号を振ると、HoLが発生する。

ので、

qpackでは別のアプローチを取る。

qpack(wip

insert key=value at INDEX INDEX 1 0 key value

reference iINDEX、、、みたいなのを定義してる

参照の証みたいなのを送り返してくるのか。

「QPACK(work in progress)。ダイナミックテーブルのスロット番号を指定してテーブルに追加。パケロスの結果、インデックス参照が先に届いちゃった場合はブロックする 」

「テーブルからの削除も明示的に送る。参照がパケロスで遅れる場合があるので、使用回数を削除コマンドに含めておく。送信側で使った回数だけ受信側で使ってなければパケロスあったとわかる」

図がいっぱいあったので見て理解したい。

state machine オブ でかい